IBIS Macromodel Task Group Meeting date: 10 September 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak * Kinger Cai Chi-te Chen Liwei Zhao Alaeddin Aydiner Sai Zhou Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): * Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: * Chulsoon Hwang * Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Samsung: Jun-Bae Kim Siemens EDA (Mentor): * Arpad Muranyi * Randy Wolff Signal Edge Solutions Benjamin Dannan Teraspeed Labs: [Bob Ross] Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that he had sent an email to ATM and the Editorial task group about a possible discrepancy in the language related to thresholds and zero- crossings in the context of PAM4. He said it might be a simple editorial correction, and we could discuss it here in ATM or in Editorial. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the August 27th meeting. Michael moved to approve the minutes. Ambrish seconded the motion. There were no objections. -------------- New Discussion: BIRD220.1 update: Yifan reviewed a presentation, IBIS SPICE Validation, which contained the results of her case study using the SPICE circuit Arpad had provided. Yifan noted that the PSIJ Sensitivity BIRD had been developed considering a driver design with a common pre-driver feeding both the pullup and pulldown devices. In that scenario, the PSIJ had proven to be independent of load, and a single keyword for PSIJ for each edge (rising/falling) was sufficient. Arpad's circuit contained different pre-drivers for the pullup and pulldown stages. Yifan set up tests into 3 different load conditions: 50 Ohms to Vcc, 50 Ohms to Vss, and 20pf to Vss. She showed results for cases with noise on the predriver rail, noise on the final stage rail, and both. The results showed that while the pre-driver PSIJ values for each of the individual pre-driver stages were still independent of load, the PSIJ of the final output varied considerably with load. Yifan investigated whether an equivalent representation using a single common predriver could be found. She studied whether a single modified input to the final driver could reproduce the behavior seen under all load conditions, but she found that this was not possible. She presented results for a case study of the 50 Ohm to Vss case. The input to the final stage was shifted over a range that produced an output variation matching the PSIJ that had been seen under that load condition. However, when this same set of shifted inputs was provided to the final stage under the other two load conditions, the results did not match the PSIJ that had been observed. Yifan concluded that the current algorithm for BIRD220.1 might be limited to cases with a common pre-driver for the pullup and pulldown stages. Arpad asked whether we could handle this by introducing two keywords, one for the pullup and one for the pulldown. Chulsoon said he thought this would be difficult. Randy said he thought the case with independent pre-drivers was much more common than the simpler case with a single pre-driver. Arpad asked what the plan for this BIRD is, given the new information? Chulsoon said they were seeking feedback. At present they don't have a workaround for the more general case. Arpad said that stating the limitation is one option. He said the current proposal would work for open drain or open source devices, which only have one transistor. It would also work for a buffer with pullup and pulldown transistors and a common pre-driver. The only issue is a buffer with pullup and pulldown transistors and independent pre-driver stages. Arpad asked how a model maker would know what's inside their buffer and whether it was suitable for BIRD220.1? He said some model makers may not be familiar with the content of the transistor level model from which they extract the data for the IBIS model, i.e., they treat it like a black box. Yifan suggested that a technique similar to what she had done to test Arpad's model might work. If the model maker determined that a single set of shifted input waveforms could duplicate the PSIJ results under all load conditions, then BIRD220.1 could be used with that device. Arpad reviewed a set of curves he had generated previously with the same SPICE model. The curves showed the rising and falling transitions when driving a resistive load into various V_fixture values. He noted that the curves for values of V_fixture between Vss and Vdd showed a plateau in the middle of the transition at the V_fixture value. He said this was the period when neither transistor was active, as the transistor turning off is shut off before the other transistor is turned on. He said this is done to eliminate crowbar currents during the transition. Arpad wondered whether this type of test, for example, looking for a plateau in the transition when driving into Vdd/2, could be used to determine whether the proposed PSIJ parameter could be applied to the model for this device. Chulsoon and Yifan agreed to draft an update to the BIRD that includes a description of the limitation. Yifan agreed to send the presentation to the ATM list. Ts4file and [Ramp]: Michael reported that the Editorial task group had discussed his draft BUG report related to the ibischk parser checking [Ramp] vs. I-V data, even when the AMI parameter Ts4file exists in the model. He said it was clear from that discussion that we needed a strategic discussion in ATM before any potential parser behavior change could be defined. Michael reviewed new proposed language in his BIRD draft. He had incorporated changes suggested at the previous meeting. He noted that he had applied the same "first order estimate" language, used to describe the purpose of [Ramp] in the presence of [External Model], to the case of Ts4file. He had also added language stating that [Ramp] data should be consistent with the behavior when the Ts4file circuit is hooked up to an identical test load. Michael asked whether EDA vendors thought [Ramp] was still necessary if Ts4file is provided. Arpad offered his high-level summary of the issues. He said no matter what types of data are provided (legacy I-V and V-t, Ts4file, [External Model]), ideally the [Ramp] data should be consistent with them, and they should be consistent with each other. He said we tend to neglect the [External Model] in this discussion, but we should be sure we are consistent there too, particularly since the Ts4file section currently mentions that [External Model] should be used if the model maker wants to provide the same electrical behavior in a non- AMI context. Michael agreed, but he said he avoided addressing the [External Model] issue because of parser complications. He said if we say [Ramp] data "should" match then the language is fuzzy and vague. However, if we say it "must" match, then we're obliged to have the parser check. He noted that Walter had said solving for a Ts4file circuit hooked up to 50 Ohms to ground was fairly easy, and the parser could implement that "simulation." However, if we say that the [Ramp] consistency check is also required for [External Model], then processing that "simulation" would be very hard for the parser. Arpad agreed that cross- checking [Ramp] vs. [External Model] was beyond the scope of the parser. Michael said one possible way around this issue would be to push the consistency checking to the EDA tool itself. If a tool supported [External Model], for example, it could check for consistency with [Ramp]. He said we might be able to define a flow or API to specify that behavior, but it would not be trivial to do. In addition, until we defined that behavior, we might still have models being issued with [Ramp] data that doesn't agree with Ts4file or [External Model] data. Arpad returned to Michael's question about [Ramp] data. He said that IBIS 7.2 says the [Ramp] keyword is required ("must"), but it does not say that it "must" match the other data. Michael agreed. He said [Ramp] is required, but the specification only mentions cross-checking with respect to the I-V tables. We don't even mention [Rising Waveform] and [Falling Waveform]. The parser, however, is more specific. When used with the -caution flag, the parser checks the dV portion of the [Ramp] data against what would be expected with the static I/V tables hooked to the same load. Michael said the IBIS Cookbook is not the law in this case, but it goes into detail about the checking. Walter agreed with Arpad that [Ramp] should still be required. He said he thought Michael's proposed "should be consistent" language was fine. He said [Ramp] is well defined and the dV/dt is a measurement. He said the tool should be allowed to assume that the [Ramp] data is correct. He said Ts4file is another way to model the device. The [Ramp] measurement should agree with the Ts4file data. If they don't agree, then it's up to the user to decide which to use and whether the model is worth using. Ambrish agreed with Walter that the "should" language was sufficient. In an ideal world it would be nice if the parser could cross check everything, but since Ts4file and [External Model] are somewhat outside of the normal scope of the IBIS parser, the checking for consistency was not required. Michael agreed, but he said the natural question that arises is what to do with with the parser checks. Right now, the parser (with -caution flag) will force the model maker to provide [Ramp] data that agrees with the I-V table data (if I-V data is provided). In a Ts4file scenario, what do we do about a tool that suffers adverse simulation effects if the [Ramp] data provided is inconsistent with the Ts4file? Ambrish said that when Ts4file was introduced, the intent was that nothing else in the .ibs file would be used in the simulation. The Ts4file was a sufficient representation of the entire buffer. If that was the intent then, why are we discussing it again? Michael said this went back to his original question about Ts4file and the parser checks. If Ts4file is intended to replace all the legacy analog IBIS information, then everything else can be ignored, and we should just have the parser stop checking all the other stuff. However, since consensus in the group is that [Ramp] should still be provided, how do we make sure the value is reasonable and doesn't cause simulation issues? Arpad said his primary concern wasn't that [Ramp] exactly match. He said as long as [Ramp] in the neighborhood it's okay. He said the problem for Michael is that the parser is checking [Ramp] vs. I-V curves when Ts4file is used. Randy said that if Ts4file is replacing everything analog in the .ibs file, then the parser could stop checking all kinds of analog keywords (e.g., monotonicity of I-V data, etc.). Ambrish noted that I-V data is not even required in an IBIS [Model]. Randy said the parser currently checks all sorts of things, even when Ts4file exists in the .ami file. Ambrish said we may not have properly cross checked all the existing language when new keywords and AMI parameters were added, but the Ts4file case should be analogous to [External Model], which is supposed to replace the legacy analog data. Walter said we have to be careful about what we mean by "replace". He said for Ts4file we should instead say "use instead of". That is, if a model uses Ts4file, then in some simulations the Ts4file data should be used and in other simulations the legacy IBIS analog data could be used. Any given simulation should use one or the other. Walter also suggested that Michael's new language stating that Ts4file is used for "initial channel characterization" should be changed to simply "channel characterization". He said the channel characterization is the initial step of an AMI analysis. Michael said that if both the Ts4file and the legacy analog information can exist in the same model, then they both need to be valid. Ambrish noted that [Ramp] had been the original keyword, and when waveform data was introduced [Ramp] was still required for tools that didn't support rising and falling waveforms. Arpad and Ambrish said that the purpose of [Ramp] and been redefined to providing "first order" bandwidth information in the [External Model] case. Ambrish said that, keeping this evolution in mind, we should review the specification again and make sure the relationship between Ts4file and [Ramp] is consistent with previous precedent. - Walter: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. New ARs: Yifan: Send her "IBIS SPICE validation" presentation slides to ATM. Yifan: Prepare a new draft of BIRD220.1 with a description of the limitation of the algorithm. Michael: Send out an updated Ts4file proposal containing changes discussed in the meeting. ------------- Next meeting: 17 September 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives